The background discussion proceeds as follows. First we recap the initial invention of p-cycles and briefly identify the most significant developments that have occurred since. The most relevant and closely related work, in terms of the driving motivation, to the present development will be that of “flow p-cycles” also known as segment-protecting p-cycles. We will therefore next discuss flow p-cycles in relatively more depth to show (as useful as that advance was and continues to be) how complex the basic problem is and how that work ultimately still failed to solve the failure dependence problem and realize a p-cycle equivalent to the SBPP scheme. We then review the SBPP scheme itself, to point out its properties. The special significance of SBPP is that in the field today, it is the pre-eminent current approach for path survivable optical networking. It is therefore relevant to appreciating the novelty and importance of FIPP p-cycles to show that all desirable properties of SBPP are also provided by FIPP p-cycles while the originally superior properties of p-cycles themselves are also retained. The following acronyms are used in this patent document: SBPP: Shared Backup Path Protection; BLSR: Bidirectional Line Switched Ring; ADM: Add Drop Multiplexer; MPLS: Multi-Protocol Label Switching; GMPLS: Generalized MPLS; IP: Internet Protocol; NEPC: Node Encircling p-Cycle; PWCE: Protected Working Capacity Envelope; PXT: Pre Cross Connected Trail; AIS: Alarm Inhibit Signal; LoS: Loss of Signal; OTDR: Optical Time Domain Reflectometry; SRLG: Shared Risk Link Group; APS: Automatic Protection Switching; DRS: Disjoint Route.
Basic P-Cycles and Related Advances to Date
The purpose of this section is to quickly recap background on p-cycles and the current state of the art with related advances on p-cycles. p-Cycles have some remarkably desirable properties but also some still-remaining shortcomings in certain regards. This review will make it apparent that despite several efforts so far, no extension to the basic p-cycles concept has yet fully addressed issues of node-failure restoration, achieving end-to-end path protection efficiency, and the desirability of not having to depend on for fault isolation.
P-Cycle History
Span protecting p-cycles, such as those described in W. D. Grover, D. Stamatelakis, “Cycle-Oriented Distributed Preconfiguration: Ring-like Speed with Mesh-like Capacity for Self-planning Network Restoration,” Proceedings of IEEE International Conference on Communications (ICC 1998), Atlanta, Ga., pp. 537-543, 7-11 Jun. 1998, were the first scheme ever to provide “ring speed with mesh efficiency” for span-restoration and is covered extensively in literature and in many patents. In protecting a network with p-cycles, one forms cyclic pre-connected closed paths of spare capacity while allowing working paths to take the shortest direct route over the facilities graph. p-Cycles are formed in advance of any failure and the switching actions required in real-time are completely pre-planned and essentially the same as that of a line-switched ring. Despite similarity to rings in that both use a cycle on the graph for their topology, p-cycles are unlike rings or cycle covers in that they protect both on-cycle and straddling failures, illustrated in FIGS. 1A to 1D. FIG. 1A shows an example of a preconfigured protection cycle (a “p-cycle”). In FIG. 1B, a span on the cycle fails and the surviving arc of the cycle is used for restoration. This action is functionally like a unit capacity BLSR. In FIGS. 1C and 1D, however, the same p-cycle is accessed to support restoration of working spans that are not on the cycle. In fact, FIGS. 1C and 1D are the more advantageous circumstances in general because two restoration routes are available from the p-cycle for such failures. Straddling spans make a significant difference to the failure coverage provided by the same investment in spare capacity in a ring compared to a p-cycle. Consider as an example the network in FIG. 2A of 11 nodes and 24 spans. In FIG. 2B, a cycle of 10 hops is configured as an example. If this cycle is used as a BLSR then each unit of protection capacity on the ring protects the same amount of working capacity on the 10 spans underlying the ring itself, shown in FIG. 2C. These are the so-called “on-cycle” failure spans. But if we use the same unit capacity cycle in FIG. 2B as a p-cycle we also access it for protection of spans such as (6-10) which is said to straddle the p-cycle. A straddling span has both its end nodes on the p-cycle, but is not itself part of the cycle. In the example, the p-cycle has nine such straddling span relationships, shown in FIG. 2D. Straddling span relationships have twice the leverage of an on-cycle span in terms of efficiency because when they fail, the cycle itself remains intact and can thereby offer two protection paths for each of unit of protection capacity. Note, in the case of a span such as (9-8), that the straddling spans are not limited to being only “inside” the p-cycle perimeter on the graph. FIG. 2E shows the resultant impact on efficiency, or conversely the redundancy. The example p-cycle can achieve ˜36% redundancy if each of its straddling spans has two units of working capacity equipped. The corresponding ring is 100% redundant. In FIG. 2F and FIG. 2G the real-time operation is illustrated. In FIG. 2F we see a BLSR-like protection reaction to an on-cycle failure. In FIG. 2G the p-cycle is accessed to protect a straddling span failure. Note the significant increase in protection coverage provided by using the same investment in spare capacity as a ring, but simply accessing it as a p-cycle. The single p-cycle of 10 hops provides protection to 19 spans and because it protects two times its own capacity on each straddling span it actually covers 28 units of working capacity, compared to the ring which protects only 10. This simple example thus yields a protection structure of only 10/28=35.7% redundancy.
Other Significant Advances
To date the further main advances in the field of p-cycles have been:                ADM-like nodal device for p-cycle networking: Extended ADMs to implement p-cycle based span-protection without using more expensive digital cross-connects, via a “capacity slice” nodal equipment architecture with most of the desirable cost and “pay as you grow” characteristics of BLSR ring Adds. (see U.S. Pat. No. 6,404,734).        MPLS-layer link-protecting p-cycles and node encircling p-cycles: Application of p-cycles to MPLS/IP packet layer applications for link protection and concept of node-encircling p-cycles (NEPCs) to provide a means for network protection against node failure. (see U.S. Patent Application Publication No. 20040133663).        Path-segment protecting p-cycles: This work, also loosely called “flow p-cycles” was the first extension of the p-cycles concept towards a path-orientation. It significantly extends the ability of the scheme to include node-failure protection (without relying on separate NEPCs) and it also gives a significant further increase in spare capacity efficiency over regular p-cycles. The main complexity of this advance is the struggle with the “mutual capacity” issue to be explained below. As a result, in the solution that flow p-cycles offers we do not obtain failure independence of end-to-end path replacement properties. (see U.S. Patent Application Publication No. 20040109407).        Protected Working Capacity Envelope (PWCE) Concept: This most recent advance is concerned with using p-cycles under the “envelope” concept to support rapid, simplified, and automated provisioning of dynamically arriving and departing requests for protected service paths through a network. While the current advance is also amenable to the envelope concept in some attractive ways, PWCE is not itself specifically only a p-cycles related advance (see G. Shen, W. D. Grover, “Performance of protected working capacity envelopes based on p-cycles: Fast, simple, and scalable dynamic service provisioning of survivable services,” Proc. Asia-Pacific Optical and Wireless Communications Conference (APOC) 2004, Beijing, China, 7-11 Nov. 2004, vol. 5626).        Pre-Cross-Connected-Trails (PXTs) and p-Trees (Protection Trees): PXTs and p-Trees are recent developments in the science of pre-configuring networks to failure. These produce designs that are complex from an operational and management perspective. Our new scheme will be compared to PXTs and p-Trees fairly. (see T. Y. Chow, F. Chudak, A. M. Ffrench, “Fast Optical Layer Mesh Protection Using Pre-Cross-Connected Trails,” IEEE/ACM Transactions on Networking, Vol. 12, No. 3, June 2004, pp. 539-547).Path Segment-Protecting P-Cycles        
Background
In the work done of path segment protecting p-cycles, such as G. Shen, W. D. Grover, “Extending the p-cycle concept to path segment protection for span and node failure recovery,” IEEE Journal on Selected Areas in Communications, vol. 21, no. 8, October 2003, pp. 1306-1319, it was explained that (paraphrasing):                “ . . . It was natural, even at the time of the first work on span-protecting p-cycles, to ask if there was a path protection equivalent to basic span-protecting p-cycles. As simple as basic p-cycles are the latter question turned out to be difficult to address. Ultimately the difficulty is how to handle the aspect of “mutual capacity” contention which is intrinsic to any path oriented or multi-commodity flow type of recovery scheme in formulating the design model under a paradigm of cyclic spare capacity structures. The corresponding operational complexity in trying to coordinate which paths can access which p-cycles, for which failures, were also beyond reach at the time.”        
In the work on flow p-cycles, these difficulties were partly overcome by allowing the insistence specifically of end-to-end path protection to be relaxed to become protection for arbitrarily defined path segments. Accordingly the concept improves on the spare capacity efficiency of regular p-cycles but it was recognized that the operational aspects were quite complicated, failure specificity remained, and the simplicity of strict end to end switchover to a predefined backup path was not achieved.
The concept of flow p-cycles is described with the aid of FIGS. 3A and 3B. FIG. 3A is an example of a span protecting p-cycle and FIG. 3B is the same cycle viewed as a flow-protecting p-cycle. In FIG. 3A the spans (0, 2), (2, 3), (3, 5), (5, 6), (6, 8), and (8, 0) are on-cycle spans of the regular p-cycle shown. The span (0, 5) is not on the cycle, but its two end nodes are, making it a straddling span. Note, however, that spans (6-7) and (7-2), and several others are “close to” being straddling spans but cannot actually be span-protected by the cycle shown. However, an individual service path that crosses both spans (6-7) and (7-2) as in FIG. 3B can be considered to straddle the cycle shown when taking a path-level view of only the one demand that flows all the way across the p-cycle. More specifically the path segment (6-7-2) can be considered to straddle the cycle shown, between the nodes 6 and 7 as long as the total working flow remains contiguous over this segment. These basic observations lead to the concept of flow- (or segment-) protecting p-cycles. Flow p-cycle designs can access more opportunities for spare-capacity-sharing than the span p-cycle method and have an additional advantage of node failure recovery. Any flow segment that intersects a flow p-cycle can be protected, not simply spans directly on, or straddling the cycle. For example, if spans (2, 7) and (6, 7) in FIG. 3A incur failures, they cannot be restored by a span-protecting p-cycle. But, under the flow p-cycle shown in FIG. 3B, the contiguous flows that traverse spans (2, 7) and (6, 7) can be restored by the cycle. Also, flow p-cycles can recover transit traffic demands due to the loss of an intermediate node on a flow. A failure of intermediate node 7 can break the flows between node pairs (1, 10) and (4, 9). The span-protecting p-cycle in FIG. 3A cannot restore these affected transit flows; however, under the flow p-cycle shown in FIG. 3B, the flows that transit node 7 can be recovered by the cycle. Note, however that any demands being added or dropped at node 7 cannot be handled by the same flow p-cycle. The flow must be unchanged in its composition between the nodes where it intersects the flow p-cycle.
Given a cycle that is a candidate to be a flow p-cycle in a network design, the relation of any given path to the cycle can be either intersecting or non-intersecting. Only intersecting paths are relevant to the consideration of each candidate cycle. A path intersects a cycle if the two have at least two common nodes (which may include the source and destination nodes of the path). These are called intersection nodes. For example, the paths between nodes (4, 9) and (1, 10) in FIG. 3B both intersect the cycle shown and are relevant to the consideration of that cycle as a possible flow p-cycle. By inspection, that cycle would provide straddling-type protection to the two segments (6-7-2) and (0-7-6) and on-cycle protection to an example flow such as (6-5-3) should it exist. More generally, a path can intersect a cycle in a variety of more complex ways, involving more than two intersecting nodes.
The various types of intersections between flow segments and prospective p-cycles have to be determined for flow p-cycle design. FIG. 4A displays the simplest scenario, where the cycle and the relevant flow segment intersect at two nodes and the flow does not share any other spans or nodes with the cycle. FIGS. 4B through 4E show other and more general intersecting flow relationships, which can be arbitrarily complex, such as in FIG. 4E. Thus, in flow p-cycles a pre-processing program is used to identify all the protection relationships between candidate cycles and the corresponding flow segments. These are fed into the design model.
Operational Aspects of Flow P-Cycles
The main new considerations in flow p-cycles (that are not needed with span p-cycles) are the need to locate and transmit information in real time and the need for a mechanism by which the flow p-cycles are employed in a failure-specific way also in real time. In flow p-cycles it is assumed that at the time a p-cycle j is established through a node x, a list of the corresponding protected flow segments that intersect the cycle at that node is recorded in association with the p-cycle. The signal_ID of the working path of which the p-cycle protects a segment is also recorded at the node for each span failure on the flow segment. In effect this data sets up matching conditions for node x to know locally which working signals (if any) it should switch into p-cycle j, depending on which span fails on any of the flow segments passing through it. Upon failure, node x is either adjacent to the failure, in which case it sees LoS, or AIS is inserted downstream by the two nodes adjacent to the failure. All working signals bear a unique signal_ID in their overheads and, any time a node inserts AIS, it appends the ID of the incident span that has failed. Thus, the failure indication data {AIS, Signal_ID=Z, span_ID=k} passes through all nodes on the failed path. But only node x will have been “pre-wired” with the matching conditions to associate Signal_ID=Z with locally accessible p-cycle j if an indication of its failure arrives, arising from span k. Thus a logical matching rule can be applied at any node seeing an AIS indication to quickly determine if it has a custodial responsibility to do protection switching for the failed signal. FIG. 5 summarizes the principal concept. The concept requires failure detection and AIS insertion at each node. Also described in G. Shen, W. D. Grover, “Extending the p-cycle concept to path segment protection for span and node failure recovery,” IEEE Journal on Selected Areas in Communications, vol. 21, no. 8, October 2003, pp. 1306-1319 is how the scheme may be more amenable to centralized control. A centralized control and management system maintains a database of network state and computes a suitable flow p-cycle configuration. The cross-connect commands and pre-planning information to create the desired p-cycles and to trigger failure specific p-cycle use is all downloaded based on the current set of demands being served and their protection classes. The centralized approach may suffer from the limitation of a heavy computing load and a high failure risk of the central network control manager. Thus, “flow p-cycles” are a significant extension to the basic method of p-cycles. The key idea is to define and employ p-cycles that protect segments of continuous demand flow. This frees the design from the strict requirement of protecting only spans that either form part of the cycle or lie on the cycle or directly straddle the p-cycle. But the technique protects arbitrary segments of paths determined during the capacity design phase, not end-to-end paths and it requires failure detection at each span for correct activation of the flow-protecting p-cycles in a failure-specific way. Fairly complex pre-planning information must be established and maintained at each node for each flow p-cycle going through it, so that each p-cycle knows which failed path segments it has custodial responsibility for depending on each possible span failure.
Shared Backup Path Protection (SBPP)
In a path-restorable network or a path-protected network, the reaction to a failure takes place from an end-to-end viewpoint for each service path affected by the failure. The end-to-end viewpoint means that the replacement path is determined as a completely new routing from the origin to destination node of the path. Path-oriented survivability schemes have several advantages over span-oriented techniques. SBPP is a special case of path restoration in general, where one backup path is predefined for each working path and no matter what fails on the working path, restoration is via a path assembled on demand over this one predetermined backup route. The backup route is fully disjoint from the route of the working path. In this scheme it is possible for the users to know ahead of time exactly where their service will be rerouted in a failure. This is sometimes said to be important to customers. Also, because path restoration (or protection) spreads the overall rerouting problem more widely over a network, SBPP can also usually be more capacity-efficient than span restoration designs. Node failure survivability is not as gracefully derived from span restoration techniques, but has to be obtained somewhat separately from the additional design of a set of NEPCs. Path-oriented schemes provide an inherent form of response against node failure. Another property of the SBPP scheme that can be especially useful in transparent optical networks is that fault isolation and detection is not necessary in real time to determine the restoration response. The response is the same no matter where on the working path a failure occurs. This property is called “failure independence” and it is of advantage in transparent or translucent optical networks where real-time signal monitoring may not be possible at intermediate nodes. In such networks therefore, fault isolation and detection is slow, difficult, or impossible until off-line Optical Time Domain Reflectometry (OTDR) measurements are made or such. But only the end-nodes of the path affected by a failure need to detect the failure, to activate the appropriate response and that is always just a single end-to-end switchover to the backup route. It also does not matter whether it is a node or span that failed because in both cases the end-nodes of the failed working path will simply see a loss of signal or loss of light on the specified line-cards.
On the other hand, path restoration or protection schemes are generally not as fast as their span-oriented counterpart due to the greater distances and numbers of nodes involved in signalling. SBPP in particular has to form the backup path along the preset route, after the failure, in real time. There are therefore obvious issues of scalability due to backup-sharing databases with SBPP and generally greater overall complexity is inherent with path restoration: SBPP and dynamic path restoration both involve considerations to address the “mutual capacity” issue which is the central complicating difference between span and path restoration.
It is important to note that although SBPP is a failure-independent path-oriented scheme where the protection route is completely identified in advance, spare capacity has to be cross-connected on the backup route in real-time. In this regard SBPP is somewhat mis-named: it is really best described as a pre-planned restoration scheme. In contrast FIPP p-cycles provide a true protection scheme where backup paths are completely predefined and fully pre-cross-connected prior to failure.
As so far described SBPP is like 1+1 APS where two fully disjoint paths, a working and a backup are established for each signal. For efficiency in the use of spare capacity, however, SBPP includes sharing of spare channels over the backup paths for different working path failures. The key ideas for routing under SBPP are that one tries to route the working path over the shortest or least cost path over the graph while also considering the disjoint backup routes this allows and their potential for sharing of spare capacity. Often under SBPP the working paths are called “primary” paths. Usually, but not always, there will be one or more possible backup routes between the same end nodes of the primary path. To be eligible as a backup route, a route has to have no nodes or spans in common with the route of the primary path and no spans or nodes in common with any other primary path whose backup route has any spans in common with the route being considered. Together these considerations ensure that when a primary path fails (under any single failure scenario):                a) No span or node along its backup route is simultaneously affected. This means it will be possible to assemble a backup path along that route if sufficient spare channels have been pre-planned. This can be called the self-disjointness requirement of the backup route, and is the fairly obvious condition for survivability.        b) No other primary path that is affected by the same failure has a pre-planned backup path that assumes the use of the same spare channel(s) on any span of the first primaries backup route.        
This is referred to as the failure disjointness requirement and is not actually needed to enable survivability, but is required to enable the efficient sharing of spare channels over different backup routes. This more complicated set of considerations basically makes sure that if primary A and B are both pre-planned to use a certain spare channel on span X in their backup routes, then there is no (single) failure where primaries A and B would ever both need that spare channel at the same time. (If they did, then two spare channels must be provided on span X to be used simultaneously, instead of one spare channel only, which can be shared by A and B over failures that do not happen simultaneously.)
As a last consideration, the preferred choice for the backup route (assuming there are several possibilities) is the one that requires the fewest new channels of spare capacity to be placed (or committed from the available capacity). In other words one tries to chose a backup route on which a backup path can be formed for primary A which, to the greatest extent possible, assumes the use only of spare channels already associated with other primaries that have no “shared risk” in common with primary A. Backup paths may share a spare channel because their corresponding primary paths have no common-cause failure scenarios (and so would not ever have a simultaneous need to use the shared backup channel). Technically, such primary paths are said to have no Shared Risk Link Groups (SRLG) in common. As a result, one unit of spare capacity is saved on the common span relative to dedicated 1+1 APS for the same two primary paths. Depending on network details, it has been found that if at most three to five such sharing relationships or “claims” are allowed to be established by diverse primaries on each spare channel, the minimum total investment in spare capacity can be approached.
FIG. 6A through 6D illustrates the concept of spare capacity sharing on predefined backup routes in a network context. FIG. 6A shows the network 600 used in the illustration. Four mutually disjoint working routes 602, 604, 606 and 608 are shown between node pairs A-C, E-G, L-G and L-H, respectively, in FIG. 6B. FIG. 6C shows possible routes 610, 612, 614, and 616 of the protection paths for the four primaries in FIG. 6B. For example, demand A-C follows the working route 602 along A-B-C for which the corresponding protection route is 610 along A-D-O-G-C. Since these working routes are all mutually disjoint, spare capacity can be shared on their backup routes. For example 610 along A-D-O-G-C and 612 along L-E-D-O-G share the D-O-G segment and therefore as shown in FIG. 6D require only one channel of spare capacity on D-O-G per working channel on routes 602 along A-B-C and 604 along E-P-G. The grey shaded areas in FIG. 6D indicate the three spans, DO, OG, NO where sharing is possible. Of these OG achieves maximal sharing with four separate working routes sharing a single unit of spare capacity (per unit working capacity) along the backup route. Note in FIGS. 6B to 6D that it is individual spare channels that this mechanism is organized to share and it is not possible to have these channels cross-connected in advance of failure because it is not known which of the specific backup paths in FIG. 6C might be needed until failure actually occurs. Ultimately, it is because SBPP sharing is structured on a per channel basis, over groups of mutually disjoint primaries, that SBPP requires cross-connection in real time to form actual restoration paths. Each primary plus backup path pair, viewed in isolation, thus forms a 1+1 APS-like arrangement.